Network Working Group Steve Bunch 
RFC # 472 ILL-ANTS 
NIC # 14801 March, 1973 


Illinois’ reply to Maxwell’s Request for Graphics Information, 
NIC Document 14925. 


This is a reply to Craig Maxwell’s (UCLA-NMC) "Request for graphics 
information" of 3/7/73. Further details can be obtained by contacting 
me directly. 


To date, our work in graphics has been primarily centered about support 
for several applications groups. To make the generation of beam- 
oriented graphics as painless as possible for these groups, our policy 
for supporting this type of graphics has been to emulate as closely as 
possible the CALCOMP plotter support package on the host machine, but 
with NGPO output. (Presently, before the resulting NGP can be sent to 
some of our peripherals, e.g., Gould 4800, it must be converted to 
device specifics. With the advent of ANTS MARK II and a PDP-11/45, all 
conversions will be handled locally, so all graphics flowing into our 
system will be NGP). We find this approach very labor-saving, even at 
the present slightly kludgey level. 


We also have some grey-scale work taking place on our GOULD and IMLAC. 
One group is processing satellite pictures on Illiac and will soon need 
grey-scale output, another is producing natural-resource maps, and a 
third is generating holograms. No standardization plans have been made 
for grey scale work, but if an acceptable standard is established, we 
will most likely use it. 


A small group, including myself, is currently planning an interactive 
graphics system. The system will use multiple hosts, possibly using a 
remote E&S machine for rotation, scaling, etc. We have a number of 
large hurdles that have to be jumped before we can do anything, though. 
Several of these are not graphics-specific, such as process-controlled 
FTP, inter-process coordination among hosts, and others. We had 
intended to let efficiency dictate the format of intermediate results 
shipped via the Net, with standardization being applied where it is 
helpful for minimizing effort. Since the system will be highly 
interactive and will also manipulate grey-scale data, we will need a 
higher level of graphics protocol to handle the user interface. A 
"proto-prototype" system is being used now to do some simple 
manipulations of meteorological data (e.g., contouring, 3-D plotting) 
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with an IMLAC passively displaying the NGPO pictures created. Soon, I 
hope to finish an IMLAC program that will handle some interaction with 
the mouse/keyset. I have decided to implement the following (outgoing) 
commands. 

MOVE beam to mouse position 


DRAW from last to present beam position. 


TEXT at present beam position. 


UNDO the last command (to facilitate freehand drawing and 
backspacing in TEXT). 


Other commands may be implemented as needed to do what people want to 
do, at least until an adequate interaction standard comes along. 


Note that there is implicit in the UNDO command the assumption that 
the other end of the line possesses a certain amount of memory and 
intelligence. Two possible philosophies for standardizing interaction 
are that (1) all "nodes" ("generators" or "users" of data) understand 
some set of commands and possess at least a certain amount of 
intelligence, and (2) a distinction is made between "displays" and 
"computers" (quotes because the line is fuzzy). I favor the first for 
its generality, but I suggest that the lowest level of interactive 
graphics might want to use the second for ease of implementation with 


unintelligent devices, e.g., COMPUTEK 400’s. (I do not mean to 
imply in (1) that the actual "computer" would not have a larger 
vocabulary than the actual "display" --this is inevitable with higher 


level capabilities in the protocol). 


Since we have almost no local computing power for applications work, 
all our graphics computation is done remotely (our work has been 
primarily at UCSD (B6700), USC-ISI (TENEX), and UCLA-CCN (360)). 
Because we do our work at scattered sites and are basically economic 
of labor (pronounced "lazy"), we have a lot to gain by standards and 
will be glad to cooperate as much as possible with standardization 
efforts. 


Steve Bunch 
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